Operation, Administration, and Management (OAM) messages have been proposed for use in provisioning communications sessions over communications networks for various diagnostic purposes. Proposed OAM functionality includes: OAM continuity checking used to determine whether transmitted content traverses the transport path of a connection; and also includes OAM performance monitoring which provides for the collection and maintenance of statistical information regarding a particular transport path of a monitored connection. Depending on implementation, OAM Continuity Checking functionality is enabled via the exchange of OAM-CC messages, and OAM Performance Monitoring functionality is enabled via the exchange of OAM-PM messages. Depending on the underlying transport technology of the communications infrastructure, OAM messages are encapsulated in packets, cells, frames, etc. For example, OAM-CC and OAM-PM cells are employed in providing OAM functionality over an Asynchronous Transfer Mode (ATM) communications network infrastructure.
AM functionality has been proposed and codified by standards bodies such as the ATM Forum, in respect of content transport technologies such as ATM. OAM functionality has also been proposed for MultiProtocol Label Switching (MPLS), Frame Relay (RF), etc. content transport technologies. OAM messages are conveyed in-band together with the traffic content conveyed along the transport path of the monitored connection.
Current implementations of OAM functionality include communications OAM compliant network nodes and/or interface cards which can be configured to provision OAM functionality. Prior art implementations include, required, lengthy, mundane, and error prone manual configuration of each communications network node, and manual configuration of each relevant interface card associated therewith, on an individual basis, in order to provision OAM message generation and diagnostic information collection on a per connection basis. Manual configuration includes configuring a particular OAM functionality compliant interface card to act as an OAM message source, as well configuring a corresponding OAM functionality compliant interface card to act as an OAM message sink. OAM message sources generate and inject OAM messages into the content flow conveyed in respect of a monitored connection over a communications content transport infrastructure. OAM message sinks inspect the content flow of a specific monitored connection to extract OAM messages conveyed therein.
Standard OAM functionality specifications assume full compliant adoption thereof. Therefore in prior art implementations, OAM functionality is only supported when both endpoints of the transport path are OAM functionality compliant interface cards. Depending on implementation, the network nodes associated with the endpoint interface cards may also have to support OAM functionality. Furthermore, in order for such prior art solutions to provide OAM functionality, the entire path over which OAM messages are to be conveyed should be homogenous, in the sense that, the communications network infrastructure traversed by the transport path cannot contain Inter-Carrier Interfaces (ICI), because ICI interfaces terminate OAM messages.
FIG. 1 shows an exemplary prior art homogeneous infrastructure 100 over which bi-directional OAM-CC/PM functionality is provisioned in respect of a unicast bi-directional monitored connection between endpoint interface card 102A of network node 104A and endpoint interface card 102B of network node 104B. The transport path of the monitored connection traverses intermediary network nodes 104i1, 104i2, and 104i3. Each intermediary interface card 102i is an Interworking Service Interface (ISSI) forwarding OAM messages along the transport path. Interface card 102 configuration as an OAM message source is depicted as a square with an arrow pointing away from the square; interface card 102 configuration as an OAM message sink is depicted as a square with an arrow pointing toward the square; and interface cards 102 forwarding OAM messages between the OAM message source and the OAM message sink are depicted as a slash and an arrow pointing towards the OAM message sink. In order to provide bidirectional OAM functionality for the bi-directional connection, endpoint interface card 102A is configured as a OAM message source for monitoring content conveyed in the A-to-B direction, and as a OAM message sink for monitoring content conveyed in the B-to-A direction. The endpoint interface card 102B has an opposite configuration. Typically, in accordance with prior art implementations, OAM reports are available for manual download from the end network nodes 104A and 104B respectively.
Although OAM functionality is standardized, not all deployed communication network node and interface card equipment supports OAM functionality. Co-pending U.S. patent application Ser. No. 09/624,756 entitled “Network Management Support for OAM Functionality and Method Therefore” filed Jul. 24, 2000 by Nijemcevic et al., which is incorporated herein by reference, describes a network manager and a method for provisioning OAM functionality for unicast bi-directional connections provisioned over an inhomogeneous infrastructure.
Making reference to FIG. 2, a network management system 210 retrieves 212, from a network management system repository 214, OAM configuration information, held for example in a connection record, specifying an established transport path in terms of a sequence of path points: a source interface, at least one intermediary interface, and a destination interface. The network management system 210 analyzes 216 the OAM configuration information retrieved. For each path point, the network management system 210 determines, based on the configuration of the communications network 200, if the path point is to serve as an OAM message source or sink in respect of the monitored connection. The network management system 210 generates OAM configuration commands for the selected path points that are to serve as OAM message sources and sinks, and the OAM configuration commands are issued 218 to the appropriate OAM message source and sink points for execution. Intermediary path points 202iB and 202iA represent segment endpoints to which OAM configuration commands are issued to turn OAM functionality on or off in monitoring the connection.
The centralized OAM functionality provisioning reduces the lengthy, mundane, and error prone manual configuration of interface cards in the transport path of provisioned connections in monitoring thereof, as well provides for central collection of OAM reports. If the network management system 210 determines that a fault or other critical condition is present within the communications network 200 which results in a reroute condition that affects a transport path of the monitored connection, the network management system 210 autonomously reconfigures the OAM message sources and sinks for the transport path to ensure that OAM functionality for the monitored connection is maintained. Furthermore, the network management system 210 can also generate additional OAM message source and sink point configuring commands issued to isolate a particular fault through the use of OAM continuity checking. The network management system 210 combines OAM configuration information and OAM reports with communications network infrastructure information stored in the network management system repository 212 for display to operations management personnel interacting therewith.
Network management system control of OAM setup and configuration within the managed communications network 200 provides maximum coverage for OAM-message-exchange-based monitoring achieved when the monitored connection is provisioned over inhomogeneous infrastructure. The network management system 210 enables operations management personnel to segment the transport path into sequential OAM compliant segments which support, and OAM non-compliant segments which do not support, conveyance of OAM messages. OAM configuration messages 218 are issued only to OAM compliant path segment endpoints which support conveyance OAM messages.
For monitored connections which have a termination on communications network equipment not managed by the network management system 210, only path segment endpoints on managed communications network equipment are issued OAM configuration commands to operate as OAM message sources or sinks respectively, which provides OAM coverage at least over the portion of the monitored connection provisioned over the managed communications infrastructure.
While the above referenced U.S. patent application provides substantial improvements over the prior art, only unicast connection OAM monitoring is supported.
Ensuring reliable content flow between terminations participating in multicast connection is important in provisioning communications services. Therefore there is a need to solve this issue.